One of the most important stages in the software development cycle is the debugging stage that occurs after a software product has shipped. This stage is important because the experiences of millions of users of the software product may be utilized during this stage to isolate program errors, identify frequently or infrequently used features, and to generally make the software product better. In order to capitalize on the body of user experience with the software product, however, it is necessary to obtain data from users and to route this data to the software developer.
Prior to the widespread adoption and use of the Internet, it was very difficult for software developers to obtain quality data regarding how a software product performed for a large number of users. Now, however, the Internet connects millions of users with the developers that create and debug the software they use. The Internet, therefore, allows data regarding the operation of a software product to be sent from a computer user to the developer of the product. The data may then be utilized by the developer to fix errors, also called “bugs,” in the program, to change the way the program operates by adding or removing features, and to otherwise improve the program. However, current systems for transmitting this data from a user to a software developer suffers from several drawbacks that reduce their effectiveness.
Current systems for reporting data regarding the operation of a software product generate event reports in response to the occurrence of an event within executing program code. For instance, an event report may be generated when an error occurs in the program code, when an unhandled exception is generated by the program code, when a particular line of code is encountered, or under other circumstances. Data that may assist the developer in understanding the event and in modifying the program code to ensure that it does not occur again is typically included in the event report. For instance, data describing the state of the computer when the event occurred may be included along with other data in the event report.
Once the event report has been created, an attempt is made to send the report to the developer via the Internet. If the user's computer has an online connection to the Internet, the report may be sent immediately. However, if the user's computer is not connected to the Internet at the time the transmission attempt is made, current systems are unable to transmit the report. For instance, if a laptop user does not have access to a network when an event occurs, current systems are unable to transmit an event report describing the event. The event report is typically lost and the data contained in the event report cannot be used in the further development and debugging of the software product.
Another limitation of current systems for reporting on the operation of a software product stems from the fact that these systems bother the computer user with user interface dialog boxes every time an event occurs, when the event occurs. This works well for software crashes where the seriousness of the problem requires that the user be interrupted. However, this can be distracting for the user when the seriousness of the problem does not warrant bothering the user. An example of this is when a particular line of code has been flagged by a developer to generate an event report (commonly referred to as a “ship assert”). Encountering the line of code is meaningful to the developer but meaningless to the user. Therefore, bothering the user when such an event occurs creates a less than ideal user experience.
It is with respect to these considerations and others that the present invention has been made.